Internet Protocols

🌐 27. What are network protocols, and why are they needed?

Network Protocols হলো একগুচ্ছ Rules and Standards, যা নির্ধারণ করে নেটওয়ার্কের ভেতর দিয়ে দুটি ডিভাইসের মধ্যে কীভাবে data ফরম্যাট, সেন্ড এবং রিসিভ হবে।

👉 এগুলো প্রয়োজন, কারণ দুজন ব্যক্তি যেমন ভিন্ন ভাষায় কথা বললে কেউ কাউকে বুঝতে পারে না, তেমনি কম্পিউটারের ভাষাও যদি ভিন্ন হয়, তবে তারা data আদান প্রদান করতে পারবে না। protocol নিশ্চিত করে যে, সেন্ডার ও রিসিভার উভয়েই একই নিয়ম বা ভাষা ব্যবহার করছে।

🏛️ What is the role of the IEEE and IETF in defining protocols?

• IETF (Internet Engineering Task Force): এটি ইন্টারনেটের বিভিন্ন সফটওয়্যার এবং প্রটোকলের মান উন্নয়ন করে। যেমন: TCP/IP, HTTP, DNS প্রোটোকলের স্ট্যান্ডার্ড এবং RFC (Request for Comments) তারাই মেনটেইন করে।
• IEEE (Institute of Electrical and Electronics Engineers): এরা মূলত হার্ডওয়্যার এবং ফিজিক্যাল লেয়ারের protocol এবং স্ট্যান্ডার্ড সেট করে। যেমন: Wi-Fi এর স্ট্যান্ডার্ড (IEEE 802.11) বা ইথারনেটের (Ethernet) স্ট্যান্ডার্ড।

🔓 How do proprietary protocols differ from open standards?

• Proprietary Protocols: এগুলো কোনো নির্দিষ্ট প্রতিষ্ঠান বা কোম্পানির তৈরি করা ব্যক্তিগত protocol, যা শুধু তাদের তৈরি হার্ডওয়্যার বা সফটওয়্যারেই কাজ করে (যেমন: Apple এর AirPlay বা Microsoft-এর RDP)।
• Open Standards: এগুলো সবার জন্য উন্মুক্ত (যেমন: HTTP বা TCP/IP)। বিশ্বের যে কেউ তাদের ডিভাইসে এই protocol ইমপ্লিমেন্ট করে একে অন্যের সাথে নির্বিঘ্নে যোগাযোগ করতে পারে।

---

🛡️ 28. What is the role of protocols in ensuring data transfer integrity and reliability?

info বা data যখন তারের বা হাওয়ার মাধ্যমে এক জায়গা থেকে অন্য জায়গায় যায়, তখন ফিজিক্যাল কারণে data করাপ্ট বা নষ্ট হতে পারে। নেটওয়ার্ক প্রটোকলগুলো নিশ্চিত করে যে, পাঠানো data ঠিকঠাকমতো গন্তব্যে পৌঁছাচ্ছে কি না (Reliability) এবং মাঝপথে dataর কোনো পরিবর্তন হয়েছে কি না (Integrity)।

Protocol হলো একটি নির্দিষ্ট set of rules যা দুটি device-এর মধ্যে communication কীভাবে হবে তা নির্ধারণ করে। Data transfer-এ integrity ও reliability নিশ্চিত করতে protocol বিভিন্নভাবে কাজ করে:

🔹 ১. Error Detection ও Correction

Protocol গুলো checksum, CRC (Cyclic Redundancy Check), এবং parity bit ব্যবহার করে। Sender data পাঠানোর সময় একটি checksum যোগ করে, receiver সেটা মিলিয়ে দেখে — না মিললে বুঝে data corrupt হয়েছে।

🔹 ২. Acknowledgement (ACK) ও Retransmission

TCP (Transmission Control Protocol)-এ receiver প্রতিটি packet পাওয়ার পর ACK পাঠায়। Sender নির্দিষ্ট সময়ের মধ্যে ACK না পেলে (timeout) packet আবার পাঠায় — এটাকে বলে retransmission।

🔹 ৩. Sequencing ও Reordering

Network-এ packets ভিন্ন ভিন্ন route দিয়ে আসতে পারে, ফলে out of order পৌঁছাতে পারে। Protocol sequence number ব্যবহার করে যাতে receiver সঠিক order-এ data reassemble করতে পারে।

🔹 ৪. Flow Control

Sender যদি receiver-এর চেয়ে বেশি দ্রুত data পাঠায়, তাহলে data হারিয়ে যেতে পারে। Flow control (যেমন TCP-এর sliding window) এই সমস্যা রোধ করে।

🔹 ৫. Congestion Control

Network-এ অতিরিক্ত traffic হলে congestion তৈরি হয়। TCP-এর congestion control algorithm (যেমন slow start, AIMD) data loss কমায় এবং network stable রাখে।

🔹 ৬. Handshaking

Data transfer শুরুর আগে TCP three-way handshake (SYN → SYN-ACK → ACK) দুই পক্ষের মধ্যে একটি reliable connection স্থাপন করে।

🔍 How do checksums and error-detection mechanisms work?

Checksum হলো একটি ছোট numerical value যা original data থেকে calculate করা হয়। এটা এক ধরনের "fingerprint" — data পরিবর্তন হলে checksum-ও পরিবর্তন হয়ে যায়।

⚙️ Checksum-এর Basic কাজের ধারা:

Sender Side:
Data → [Checksum Algorithm] → Data + Checksum value পাঠায়

Receiver Side:
Data + Checksum পায় → আবার Calculate করে → দুটো মেলালে ✅, না মেললে ❌

🔢 ১. Simple Checksum (Addition Method)

ধরো তুমি তিনটা number পাঠাচ্ছো: 10, 20, 30

AaPreviewClick to view details

Sender:
  10 + 20 + 30 = 60 → Checksum = 60
  পাঠায়: [10, 20, 30, 60]

Receiver:
  10 + 20 + 30 = 60 → Match ✅ (data intact)

যদি data corrupt হয়:
  10 + 25 + 30 = 65 ≠ 60 → Mismatch ❌ (error detected!)

🔄 ২. CRC (Cyclic Redundancy Check)

এটা সবচেয়ে বেশি ব্যবহৃত এবং powerful error detection method।

Basic Idea:

• Data-কে একটা বড় binary number হিসেবে ধরা হয়।
• একটা নির্দিষ্ট divisor (generator polynomial) দিয়ে ভাগ করা হয়।
• Remainder টাই হলো CRC value — এটা data-র সাথে পাঠানো হয়।
• Receiver একই ভাগ করে — remainder 0 হলে data ঠিক আছে।

AaPreviewClick to view details

Sender:
  Data ÷ Generator = Quotient + Remainder (CRC)
  পাঠায়: Data + CRC

Receiver:
  (Data + CRC) ÷ Generator = Remainder 0 ✅ → No error
                             = Remainder ≠ 0 ❌ → Error detected!

💡 CRC কোথায় ব্যবহার হয়: Ethernet, Wi-Fi, ZIP files, hard disk storage।

⚖️ ৩. Parity Bit

এটা সবচেয়ে simple error detection।

• প্রতিটা data byte-এর সাথে একটা extra parity bit যোগ করা হয়।
• Even parity: total 1-এর সংখ্যা even রাখা হয়।
• Odd parity: total 1-এর সংখ্যা odd রাখা হয়।

Data: 1010001  → 1 এর সংখ্যা = 3 (odd)
Even parity bit = 1 যোগ করো → 10100011 (এখন 4টা 1, even ✅)

Receiver পেলো: 10100111 → 1 এর সংখ্যা = 5 (odd) ❌ Error!

⚠️ সীমাবদ্ধতা: Parity bit শুধু single-bit error ধরতে পারে, দুটো bit একসাথে পরিবর্তন হলে ধরতে পারে না।

🔐 ৪. MD5 / SHA (Cryptographic Hash)

File download বা security-তে ব্যবহৃত হয়।

• পুরো file বা message থেকে একটা fixed-size hash value তৈরি হয়।
• Data-র সামান্য পরিবর্তনেও সম্পূর্ণ আলাদা hash আসে।
• MD5 → 128-bit hash, SHA-256 → 256-bit hash।

"Hello"  → MD5 → 8b1a9953c4611296a827abf8c47804d7
"Hello!" → MD5 → 9c7d5b... (সম্পূর্ণ আলাদা!)

🆚 Error Detection vs Error Correction

বিষয়	Error Detection	Error Correction
কী করে	শুধু error আছে কিনা বলে	Error ঠিকও করে দেয়
উদাহরণ	CRC, Checksum, Parity	Hamming Code, Reed-Solomon
ব্যবহার	Network transmission	CD/DVD, satellite communication

---

🌍 29. What are the key protocols: HTTP, HTTPS, FTP, and SMTP?

ইন্টারনেটের বিভিন্ন কাজের জন্য ডেডিকেটেড কিছু প্রটোকল রয়েছে:

• 🌐 HTTP (HyperText Transfer Protocol): ওয়েব সার্ভার এবং ব্রাউজারের মধ্যে ওয়েব পেজের data আদান-প্রদান করতে ব্যবহৃত হয় (সাধারণত পোর্ট 80-তে)।
• 🔒 HTTPS (HTTP Secure): এটি HTTP-এর সিকিউর ভার্সন, যা আদান-প্রদান হওয়া data-কে এনক্রিপ্ট করে সিকিউরিটি দেয় (পোর্ট 443)।
• 📁 FTP (File Transfer Protocol): ইন্টারনেটের মাধ্যমে এক কম্পিউটার থেকে অন্য কম্পিউটারে বড় ফাইল আপলোড বা ডাউনলোড করার প্রটোকল।
• 📧 SMTP (Simple Mail Transfer Protocol): একটি সার্ভার থেকে অন্য সার্ভারে ইমেইল সেন্ড বা রাউট করার জন্য ব্যবহৃত প্রটোকল।

⚠️ Why is FTP considered insecure, and what are its modern alternatives (SFTP, FTPS)?

• ইনসিকিউর কেন: ট্র্যাডিশনাল FTP data এবং পাসওয়ার্ডগুলোকে সম্পূর্ণ "প্লেইন টেক্সট" বা আন-এনক্রিপ্টেড (Unencrypted) অবস্থায় পাঠায়। ফলে কোনো হ্যাকার নেটওয়ার্কে স্নাইফ (sniff) করলে সহজেই পাসওয়ার্ড চুরি করতে পারে।
• মডার্ন বিকল্প (Alternatives):
  • SFTP (SSH File Transfer Protocol): এটি আলাদা একটি protocol যা পুরো ফাইল data-কে SSH টানেলের মধ্য দিয়ে এনক্রিপ্ট করে পাঠায়, ফলে এটি অত্যন্ত সুরক্ষিত।
  • FTPS (FTP over SSL/TLS): এটি পুরোনো FTP-এর উপরেই TLS বা SSL এনক্রিপশনের লেয়ার যুক্ত করে তৈরি করা হয়েছে।

⏱️ Why is SMTP usually not used for real-time chat? Which protocol is better suited for that?

• SMTP রিয়েল-টাইম নয়: SMTP ডিজাইন করা হয়েছে ইমেইল পাঠানোর জন্য এবং এটি স্টোর-অ্যান্ড-ফরওয়ার্ড (Store-and-forward) মডেলে চলে। সার্ভার মেসেজ রিসিভ করে স্টোর করে, এরপর প্রাপকের সার্ভারে পাঠায়। এভাবে কয়েক ধাপে পার হতে বেশ কিছু সময় (কয়েক সেকেন্ড বা কয়েক মিনিট) লেগে যায়, যা রিয়েল-টাইম চ্যাটের জন্য মোটেও উপযুক্ত নয়।
• উপযুক্ত protocol: রিয়েল টাইমে ইনস্ট্যান্ট মেসেজিং এর জন্য WebSocket, XMPP, বা MQTT অনেক ভালো protocol, কারণ এগুলো সার্বক্ষণিক লাইভ কানেকশন তৈরি করে রাখে এবং সার্ভার থেকে কোনো ডিলে ছাড়াই ক্লায়েন্টকে পিন বা পুশ (Push) করতে পারে।

---

🔒 30. How do secure protocols like HTTPS ensure encrypted communication?

HTTPS (HyperText Transfer Protocol Secure) হলো HTTP-র secure version। এটা TLS (Transport Layer Security) protocol ব্যবহার করে data encrypt করে, যাতে কেউ মাঝপথে data পড়তে বা পরিবর্তন করতে না পারে।

HTTP:   Data পাঠায় plain text-এ → যে কেউ পড়তে পারে ❌
HTTPS:  Data পাঠায় encrypted-এ → কেউ পড়তে পারে না ✅

🎯 HTTPS-এর তিনটা মূল লক্ষ্য:

লক্ষ্য	মানে কী
Confidentiality	Data কেউ পড়তে পারবে না।
Integrity	Data মাঝপথে পরিবর্তন হবে fix না।
Authentication	Server আসল কিনা যাচাই করা।

🤝 What is the TLS handshake process in detail?

TLS Handshake হলো Client ও Server-এর মধ্যে একটা প্রাথমিক চুক্তি প্রক্রিয়া — যেখানে তারা encrypted communication শুরু করার আগে একে অপরকে চেনে, বিশ্বাস করে এবং একটা shared secret key তৈরি করে।

ধাপসমূহ:

1. 🙋‍♂️ ClientHello: Browser প্রথমে Server-কে একটা message পাঠায়, যেখানে থাকে তার সাপোর্টেড TLS version, cipher suites এবং একটা random number।
2. 🙋‍♀️ ServerHello: Server reply করে এবং জানায় কোন TLS version ও cipher suite ব্যবহৃত হবে, সাথে Server-এর নিজের random number।
3. 📜 Certificate পাঠানো: Server তার SSL/TLS Certificate (Public Key, CA signature, expiry date) পাঠায়।
4. 🔍 Certificate Verify: Browser নিজে CA-র Public Key দিয়ে signature যাচাই করে।
5. 🔑 Key Exchange: Client একটা "pre-master secret" তৈরি করে Server-এর Public Key দিয়ে encrypt করে পাঠায়।
6. 🧩 Session Key তৈরি: Client ও Server উভয়েই নিজ নিজ random number ও pre-master secret দিয়ে একটাই "Symmetric Session Key" তৈরি করে।
7. ✅ Finished Message: উভয় পক্ষ নতুন Session Key দিয়ে encrypt করে message পাঠায়।
8. 🚀 Encrypted Data Transfer: এরপর থেকে সব data "AES symmetric encryption" দিয়ে encrypt হয়ে আদান-প্রদান হয়।

📌 What is certificate pinning and when is it used in backend applications?

Certificate Pinning হলো ক্লায়েন্ট অ্যাপ্লিকেশন (যেমন মোবাইল অ্যাপ বা IoT ডিভাইস) এর ভেতরে নির্দিষ্ট কোনো সার্ভারের পাবলিক-কী বা সার্টিফিকেটের হ্যাশ সরাসরি হার্ডকোড (hardcode) করে দেওয়া।

• ব্যবহার: এটি Man-in-the-Middle (MitM) অ্যাটাক প্রতিরোধ করে। কারণ কেউ যদি ফেক সার্টিফিকেট দিয়ে ধোকা দেওয়ার চেষ্টা করে, অ্যাপটি তখনই কানেকশন রিজেক্ট করে দেবে যেহেতু সেটি তার হার্ডকোড করা সার্টিফিকেটের সাথে মেলে না।

---

📚 31. What are protocol stacks, handshakes, and encryption?

• 🥞 Protocol Stack: এটি হলো প্রোটোকলগুলোর একটি স্তরবিন্যাস (যেমন OSI বা TCP/IP মডেল)। এখানে নিচের স্তরের protocol ওপরের স্তরের প্রোটোকলকে সার্ভিস বা সেবা দেয়।
• 🤝 Handshakes: কোনো কানেকশন স্টাবলিশ করার আগে দুটি ডিভাইস যখন নিজেদের মধ্যে কিছু নিয়ম এবং কনফিগারেশন সেট করার জন্য প্রাথমিক মেসেজ বিনিময় করে, তাকে হ্যান্ডশেক বলে (যেমন TCP 3-way handshake)।
• 🔐 Encryption: data-কে এমন একটি অগাধ বা দুর্বোধ্য ফরম্যাটে পরিবর্তন করা, যা শুধুমাত্র অনুমোদিত রিসিভার ছাড়া আর কেউ পড়তে পারে না।

🗺️ How does the TCP/IP stack map to the OSI model?

OSI মডেলের ৭টি লেয়ারের বিপরীতে বাস্তব জীবনে ব্যবহৃত হওয়া TCP/IP মডেলে ৪টি লেয়ার থাকে:

• Application Layer (TCP/IP): এটি OSI মডেলের উপরের তিনটি লেয়ারকে (Application, Presentation, Session) একসাথে কভার করে। (যেমন: HTTP, FTP)
• Transport Layer (TCP/IP): এটি হুবহু OSI-এর Transport layer এর সমতুল্য। (যেমন: TCP, UDP)
• Internet Layer (TCP/IP): এটি OSI-এর Network layer এর সমতুল্য। (যেমন: IPv4, IPv6)
• Network Access Layer (TCP/IP): এটি OSI-এর নিচের দুটি লেয়ার (Data Link এবং Physical) নিয়ে গঠিত।

🕵️‍♂️ What is forward secrecy and why does it matter?

Forward Secrecy (বা Perfect Forward Secrecy - PFS) হলো এনক্রিপশনের এমন একটি বৈশিষ্ট্য, যা প্রতিটি নতুন সেশনের জন্য সম্পূর্ণ ইউনিক এবং নতুন সেশন-কী (Session Key) জেনারেট করে।

• কেন গুরুত্বপূর্ণ? হ্যাকার যদি আজ থেকে ৫ বছর পর কোনোভাবে সার্ভারের প্রাইভেট-কী (Private Key) হ্যাক করেও ফেলে, তবুও সে আগের রেকর্ড করা বা ক্যাপচার করা ট্রাফিক বা চ্যাটগুলো ডিক্রিপ্ট করে মেলাতে পারবে fix না। কারণ তখনকার সেশন-কী গুলো প্রাইভেট কী এর ওপর নির্ভরশীল ছিল না এবং তা ব্যবহার করার সাথে সাথেই ডিস্ট্রয় বা বাতিল হয়ে গিয়েছিল।

---

🏛️ 32. What is the OSI model, and how does it relate to Internet protocols?

OSI (Open Systems Interconnection) Model হলো একটি থিওরেটিক্যাল কনসেপ্ট বা রেফারেন্স মডেল। নেটওয়ার্কে একটি ডিভাইস থেকে আরেকটি ডিভাইসে ইন্টারনেট প্রটোকলগুলো কীভাবে data পাঠায়, তা বুঝতে সাহায্য করার জন্য পুরো প্রক্রিয়াটিকে ৭টি ধাপে বা লেয়ারে ভাগ করা হয়েছে। ইন্টারনেট প্রোটোকলগুলো (যেমন HTTP, TCP) মূলত এই লেয়ারগুলোতে অবস্থান করে।

📦 Can you explain each of the 7 OSI layers with a real-world example?

একটি চিঠি বা পার্সেল পাঠানোর উদাহরণ দিয়ে ভাবা যাক:

1. Application Layer (লেয়ার ৭): যেই অ্যাপটি আমি ব্যবহার করছি (যেমন ব্রাউজার বা Email)। এখানে HTTP বা SMTP কাজ করে।
2. Presentation Layer (লেয়ার ৬): আমি চিঠিটা কোন ভাষায় (Data Formatting) বা এনক্রিপশনে (TLS) লিখব, তা ঠিক করে।
3. Session Layer (লেয়ার ৫): সংযোগ স্থাপন করা এবং সংযোগ ধরে রাখা (Connection established)।
4. Transport Layer (লেয়ার ৪): চিঠির বড় অংশগুলোকে ছোট ছোট সেগমেন্টে ভাগ করা (TCP/UDP)। এই লেয়ার নিশ্চিত করে চিঠিটা ঠিকমতো পৌঁছাবে কি না।
5. Network Layer (লেয়ার ৩): এখানে IP কাজ করে। প্যাকেটের গায়ে সেন্ডার এবং রিসিভারের অ্যাড্রেস এবং রুট বসানো হয়।
6. Data Link Layer (লেয়ার ২): এখানে MAC অ্যাড্রেস যুক্ত করে ফ্রেম তৈরি করা হয়। রাউটারে এক হপ থেকে পরের হপে কীভাবে যাবে তার ফিজিক্যাল গ্যারান্টি দেয়।
7. Physical Layer (লেয়ার ১): এটি একেবারে ফিজিক্যাল। চিঠিটা ডেলিভারি ম্যানের হাতে বা ফাইবার অপটিক ক্যাবল হয়ে সিগন্যালে পরিণত হয়।

🧱 At which OSI layer do firewalls typically operate?

• Network & Transport Layer (লেয়ার ৩ এবং ৪): ট্রাডিশনাল (Packet-filtering) ফায়ারওয়ালগুলো সাধারণত আইপি অ্যাড্রেস এবং পোর্ট নাম্বারের ওপর ভিত্তি করে রুলস তৈরি করে কাজ করে।
• Application Layer (লেয়ার ৭): আধুনিক বা Next-Generation Firewalls (NGFW) এবং Web Application Firewalls (WAF) গুলো অ্যাপ্লিকেশনের কনটেন্ট (যেমন HTTP রিকোয়েস্টের হেডার, পেলোড) রিড করে, যা অ্যাপ্লিকেশন লেয়ারে কাজ করে।

---

🔢 33. What is the difference between IPv4 and IPv6, and why is IPv6 important?

ইন্টারনেটের প্রসার বাড়ার কারণে ৩২-বিটের IPv4 (যেমন 192.168.0.1) অ্যাড্রেসগুলো শেষ হয়ে যাচ্ছে। তাই ১২৮-বিটের IPv6 অ্যাড্রেসের প্রয়োজন দেখা দিয়েছে, যা ট্রিলিয়ন ট্রিলিয়ন নতুন অ্যাড্রেস স্পেস তৈরি করতে পারে এবং এর রাউটিং এফিশিয়েন্সি ভালো।

📝 What is IPv6 address notation and how does it differ from IPv4?

• IPv4: এটি ডেসিমাল বা দশমিক সংখ্যায় (০-২৫৫) লেখা হয় এবং প্রতি ভাগে ডট (.) ব্যবহার করা হয়। এর ৪টি ব্লক থাকে। (যেমন: 203.0.113.5)
• IPv6: এটি হেক্সাডেসিমাল (Hexadecimal) বা ষোড়শমিক সংখ্যায় লেখা হয় এবং প্রতি ব্লকে কোলন (:) ব্যবহার করা হয়। এর ৮টি ব্লক থাকে। (যেমন: 2001:0db8:85a3:0000:0000:8a2e:0370:7334)। শূন্যগুলো সংক্ষেপ করার উপায়ও (::) এখানে বিদ্যমান।

🚧 What challenges arise when migrating a backend system from IPv4 to IPv6?

ব্যাকএন্ড সিস্টেমে আইপি মাইগ্রেশনের ক্ষেত্রে কিছু জটিলতা তৈরি হয়:

• কমপ্যাটিবিলিটি: সব নেটওয়ার্ক বা ডিভাইস এখনো IPv6 সাপোর্ট করে না। তাই "Dual Stack" ইমপ্লিমেন্ট করতে হয় (দুটি আইপিই একসাথে রান করানো)।
• Database স্টোরেজ: অনেক লেগাসি সিস্টেমে আইপি অ্যাড্রেস সংরক্ষণের জন্য ডাটাবেসের ফিল্ড VARCHAR(15) রাখা হত (IPv4 এর জন্য)। কিন্তু IPv6 এর জন্য VARCHAR(39) বা এর বেশি জায়গা দরকার।
• IP Parsing Logic: আইপি পার্সিং বা IP থেকে ইউজারের লোকেশন ট্র্যাকিং এর জন্য ব্যবহৃত থার্ড-পার্টি লাইব্রেরিগুলো যদি IPv6 এর জন্য আপডেট না করা থাকে তবে বাগ হতে পারে।

---

⚡ 34. What is WebSocket, and how does it differ from HTTP for real-time communication?

WebSocket হলো একটি আধুনিক কমিউনিকেশন protocol, যা ক্লায়েন্ট এবং সার্ভারের মধ্যে একটি বাই-ডিরেকশনাল (Bidirectional), ফুল-ডুপ্লেক্স (Full-duplex) এবং পারসিস্টেন্ট (Persistent) কানেকশন তৈরি করে রাখে।

• সাধারণ HTTP তে ক্লায়েন্ট রিকোয়েস্ট না করলে সার্ভার নিজ থেকে নিজে কিছু পাঠাতে পারে না। কিন্তু যদি রিয়েল-টাইম ডাটা (যেমন চ্যাটিং, লাইভ স্কোর) দরকার হয়, তবে HTTP তে বারবার রিকোয়েস্ট (Polling) পাঠাতে হয়, যা ব্যান্ডউইথ নষ্ট করে।
• WebSocket শুরুতেই একটি কানেকশন ওপেন করে রাখে, ফলে রিকোয়েস্টের দরকার হয় না, সার্ভার তার ইচ্ছামতো রিয়েল-টাইমে যেকোনো মুহূর্তে ক্লায়েন্টকে data পুশ (Push) করতে পারে।

🤝 What is the WebSocket handshake process?

WebSocket পোর্ট 80 বা 443 ব্যবহার করেই কাজ করে।

• ক্লায়েন্ট প্রথমে সাধারণ একটি HTTP GET রিকোয়েস্ট পাঠায়। কিন্তু এই রিকোয়েস্টের হেডারে Upgrade: websocket এবং Connection: Upgrade লেখা থাকে।
• সার্ভার যদি ওয়েবস্কট সাপোর্ট করে, তবে সে স্ট্যাটাস কোড 101 Switching Protocols দিয়ে রেসপন্স করে।
• এরপর থেকে HTTP এর বদলে একই TCP কানেকশনের উপর দিয়ে WebSocket এর রুলস অনুযায়ী ফুল-ডুপ্লেক্স data আদান-প্রদান শুরু হয়।

🔌 How does Socket.IO build on top of WebSocket?

Socket.IO সরাসরি WebSocket নয়, বরং এটি একটি লাইব্রেরি বা র‍্যাপার (Wrapper) যা রিয়েল-টাইম ফিচারগুলোকে আরো সহজ করে ডেভেলপমেন্ট করা যায়।

• নিজস্ব ফিচার: অটো-রিকানেকশন (Auto-reconnection), ব্রডকাস্টিং (Broadcasting), এবং মাল্টিপ্লেক্সিং বা রুম (Rooms & Namespaces) সাপোর্ট।
• ফলব্যাক মেকানিজম: যদি কোনো পুরাতন ব্রাউজারে WebSocket সাপোর্ট না থাকে, তবে Socket.IO নিজে থেকেই HTTP Long-polling -এ সুইচ (fallback) করে রিয়েল-টাইম আচরণ বজায় রাখে।

📡 When would you choose Server-Sent Events (SSE) over WebSocket?

SSE (Server-Sent Events) হলো ওয়ান-ওয়ে (One-way) বা একমুখী কমিউনিকেশন।

• যদি অ্যাপ্লিকেশনটিতে শুধুমাত্র সার্ভার থেকে ক্লায়েন্টের দিকে প্রতিনিয়ত আপডেট পাঠানোর দরকার হয় (যেমন: লাইভ নিউজ ফিড, স্টক টিক্কার বা নোটিফিকেশন), এবং ক্লায়েন্ট থেকে সার্ভারের দিকে বারবার মেসেজ পাঠানোর দরকার না থাকে, তবে WebSocket এর জায়গায় SSE ব্যবহার করা উচিত। এটি সাধারণ HTTP ব্যবহার করেই কাজ করে এবং সেটআপ করা অনেক সহজ।

---

🚀 35. How does gRPC compare to HTTP for backend API communication?

gRPC (gRPC Remote Procedure Calls) হলো গুগলের তৈরি করা একটি অত্যাধুনিক এবং হাই-পারফরম্যান্স ওপেন সোর্স RPC ফ্রেমওয়ার্ক।

• সাধারণ REST API (যা HTTP 1.1 এবং JSON ব্যবহার করে) এর তুলনায় gRPC অনেক ফাস্ট এবং ইফিসিয়েন্ট।
• কারণ gRPC নিজে থেকেই HTTP/2 protocol ব্যবহার করে (যা মাল্টিপ্লেক্সিং সাপোর্ট করে) এবং JSON এর র-টেক্সটের পরিবর্তে Protocol Buffers নামক বাইনারি সিরিয়ালাইজেশন ফরম্যাট ব্যবহার করে। এটি মূলত মাইক্রোসার্ভিস আর্কিটেকচারে এক সার্ভার থেকে আরেক সার্ভারে (Server-to-Server) ইন্টারনাল কমিউনিকেশনের জন্য সবচেয়ে বেশি ব্যবহৃত হয়।

📦 What is Protocol Buffers (protobuf) and why does gRPC use it?

Protocol Buffers (বা Protobuf) হলো data সিরিয়ালাইজ করার একটি মেকানিজম বা ডাটা ফরম্যাট।

• JSON এর মতো এতে ব্র্যাকেট বা কমার মতো মানুষের পড়ার উপযোগী ক্যারেক্টার থাকে না। এটি data-কে কমপ্লেসড বাইনারি (0 এবং 1) ফর্মেটে রূপান্তর করে।
• এর কারণে data-র সাইজ অনেক ছোট হয়ে যায় এবং নেটওয়ার্কে দ্রুত পার হতে পারে। data-র সাইজ ছোট হওয়ায় CPU-এর পার্সিং ল্যাটেন্সিও কমে যায়, যা gRPC কে এত দ্রুত করে তোলে।

🔄 What are the four types of gRPC communication?

gRPC চারটি ভিন্ন ধরণের মেসেজিং মেকানিজম সাপোর্ট করে:

1. Unary RPC: এটি নরমাল API এর মতো। ক্লায়েন্ট একটি সিঙ্গেল রিকোয়েস্ট পাঠায় এবং সার্ভার একটি সিঙ্গেল রেসপন্স দেয়।
2. Server Streaming RPC: ক্লায়েন্ট একটি রিকোয়েস্ট পাঠায়, কিন্তু সার্ভার উত্তরের লম্বা একটি স্ট্রিম (Stream) বা পরপর অনেকগুলো data পাঠাতে থাকে (যেমন একটি ফাইল ডাউনলোড)।
3. Client Streaming RPC: ক্লায়েন্ট একটি data-র স্ট্রিম বা প্রচুর data পাঠাতে থাকে, আর সার্ভার সবগুলো রিসিভ করে সবশেষে একটি সিঙ্গেল রেসপন্স দেয় (যেমন বড় ফাইল আপলোড)।
4. Bidirectional Streaming RPC: ক্লায়েন্ট এবং সার্ভার দুজনেই স্বাধীনভাবে একে অপরের সাথে একই সাথে data স্ট্রিম করতে থাকে, অনেকটা চ্যাট অ্যাপ্লিকেশনের মতো।

🤔 When would you choose gRPC over REST?

• যখন মাইক্রোসার্ভিস আর্কিটেকচারে ইনটার্নাল সার্ভিসগুলোর মধ্যে অত্যন্ত দ্রুত যোগাযোগ স্থাপন করতে চাইবেন।
• যখন প্রচুর পরিমানে data (High throughput) আদান-প্রদান করতে হবে বা কম ল্যাটেন্সি (Low latency) দরকার হবে।
• যেখানে ক্লায়েন্ট এবং সার্ভার উভয়দিক থেকেই স্ট্রিমিং (Streaming) সাপোর্ট প্রয়োজন হবে।
• তবে, যদি ব্রাউজার বা সাধারণ পাবলিক ইন্টারনেট এপিআই (Public API) বানাতে হয়, তবে gRPC এর চেয়ে REST বা GraphQL ভালো, কারণ ব্রাউজারগুলো এখনও নেটিভভাবে gRPC ভালোভাবে সাপোর্ট করে না।